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(54) Communications addressing network 

(57) A communications addressing network (100) includes a communication terminal (101) and at least a first 
network node (103) for communicating between a first communication terminal (101) and a second 
communication terminal (105). This communications addressing network (100) allows a calling user to create a 
communication request for communicating to the second communication terminal (105). The communication 
request includes commonly known information such as an end users name, an organization that the end user 
is associated with and a type of service used to communicate. 
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At least one drawing originally filed was informal and the print reproduced here is taken from a later filed formal copy. 
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A COMMUNICATIONS ADDRESSING NETWORK AND 
TERMINAL THEREFOR 

Field of the Invention 

Generally, the present invention concerns 
communications and more particularly, a unique 
communications network for providing addressing and 
communications of multiple services to multiple users. 

Background of the Invention 

Today, there are a large number of communication 
addressing schemes available. Each addressing scheme 
requires a new identity for a particular individual, thus, 
creating an exhaustive list of identities to reach a 
particular individual. An example of such identities 
include home telephone number, home fax number, 
cellular phone number, pager number, work telephone 
number, work fax number, and internet address. 

This list of communication identities creates 
incredible complexity for a user. First, in order to 
communicate with an end user the calling user must 
store and recover the appropriate communication 
identity for the desired communication service for that 
particular user. Second, the calling user must be familiar 
with the different methods of entering the different 
telecommunication identities such as E-mail and voice 


137A I > 


communications. Third, the user may need to change his 
communication identities as the individual networks 
grow or identities are reallocated. Thus, it would be 
desirable for a calling user to be able to communicate to 

5 an end user merely by identifying the end user and the 
service which the calling user wishes to use for his 
communication. Such a system, if provided, would allow 
the calling user to operate more efficiently with less 
frustration by allowing the calling user to forget all of the 

10 individual communication identities as well as minimize 
the methods by which to enter the different 
communication modes. 

Brief Description of the Drawings 

FIG. 1 is an illustration in block diagram form ot a 
communications addressing network in accordance with 
the present invention. 

FIG. 2 is an illustration in block diagram form of a 
20 communication terminal in accordance with the present 
invention. 

FIG. 3 is an illustration of a network node in 
accordance with the present invention. 

FIG. 4 is an illustration of an example communication 
25 scenario in accordance with the present invention. 

FIG. 5 is an illustration of an example communication 
scenario in accordance with the present invention. 
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Detailed Description of a Preferred Embodiment 

A preferred embodiment of the present invention is 
5 an implementation of a communications addressing 

network including a communication terminal and at least 
a first network node for communicating between a first 
communication terminal and a second communication 
terminal. This communications addressing network 

1 0 allows a calling user to create a communication request 
for communicating to the second communication 
terminal. The communication request includes commonly 
known information such as an end users name, an 
organization that the end user is associated with and a 

1 5 type of service used to communicate. 

FIG. 1 is an illustration in block diagram form of a 
communications addressing network 100. The network 
100 includes a first communication terminal 101, a 
network node 103 and a second communications terminal 

20 105. The communication terminals 101, 105 and the 
network node 103 are interconnected via a 
communication link 107. This communication addressing 
network 100 is a simplified illustration of a system that 
may use the present invention. Other equally sufficient 

25 embodiments are included in the scope of the present 
invention. Other such embodiments include: multiple 
communication units in excess of two; multiple network 
nodes; and multiple communication links containing 
multiple communication terminals and multiple network 

30 nodes. 
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FIG. 2 is a detailed block diagram illustrating a 
communication terminal such as communication terminal 
101. It is understood that the communications terminal 
can be realized in any one of a multiplicity of devices. 
5 Such devices include a telephone, a computer terminal, a 
personal digital assistant (PDA) or any other 
communication device that incorporates the below 
described functions. Alternatively, it is understood that 
the communication terminal in such a system could have 
10 limited functionality, thus, the network nodes would 
provide all of the addressing capabilities. This would 
allow the communications addressing network described 
herein to be accessed by the communication terminals 
that are available today. In the preferred embodiment, 
15 the communication terminal 101 includes a man-machine 
interface (MMI) 201, an identity manager 203, a domain- 
user database 205, a search domain database 207, a node 
to node controller 209 and a call manager 211. 

The MMI 201 provides the user with an interface to 
20 set up communications and make inquiries about other 
users. The MMI 201 also provides an interface for the 
user to modify any of the records stored in the Domain- 
User database and the Search Domain Database. 
The MMI 201 detects the input of a called user identity 
25 and creates a communication request. The 

communication request is generated by converting the 
input user identity into the required format via voice to 
text processing, input text processing or some other 
means as appropriate for the interface and presents this 
30 correctly formatted information to the Identity Manager 
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203 so that the information can be used to identify an 
appropriate Service Access Point Identification (SAP ID). 
If a user enters a SAP ID or other routing information 
directly in association with a communication request (as 
5 is normally the case today), the MMI 201 instructs the 
call manager 211 to set up a communication to the SAP 
ID or to follow the appropriate routing instructions. 
Otherwise, the MMI 201 creates a communication request 
having several fields representing real world information 
10 for identifying an end user. These fields might for 
example include the called user's name (e.g. Bill 
Robinson), the called users organisation (e.g. Motorola), 
the called user's address or partial address (e.g. 
Basingstoke, UK). Alternatively, the called user's identity 
15 can be in the form of a key word which is used in 

association with information about the calling user to 
identify the called user (e.g. keyword = "wife", Calling 
user = "Bill Robinson, 15 Wentworth Close"). The identity 
manager 203 identifies the SAP ID for the end user in 
20 response to the communication request from the MMI 

201. The identity manager 203 has several resources for 
identifying the appropriate SAP ID. 

The first resource is the domain user database 205 
which is a local database created by the communication 
25 terminal 101. The domain user database stores 

individual records for particular users. The identity 
manager searches this domain-user database and 
attempts to match the records of the communication 
request with those contained in the domain user 
30 database. This database contains records for each user 
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known to the first communication terminal 101 and for 
each communication service for which the user has 
access. In the preferred embodiment, the contents of the 
information stored in each record is as follows: 

5 

Unique Access Keyword/Calling ID 
User Name 
Organisation 
Access Control Rule 
10 Address 

Prioritised Dialable Number(s) 

Present Domain ID 

Service 

Charging Information 
15 Prioritised list of Gateway Domains 
SAP ID 
Routing Path 

Essentially, the Domain-User Database allows a variable 
20 set of fields to be used as keys to match against a 

complete record stored in the database. When a match is 
found, the complete matching record(s) is(are) returned. 
The purpose of the Domain-User Database is to provide 
the communication terminal with the information it 

25 needs to match the called user's identity and retrieve a 
SAP ID or alternative identity (e.g. routing path) to allow 
the system to route a communication to the required 
destination. In addition, the database contains 
information which will allow a matching of the desired 

30 communication service to a communication service 
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provided by the called user's communication terminal. 
The database contains a number of additional items of 
information which are used to support specific 
telecommunications capabilities, such as mobility and 
5 calling user restriction. A description of the use of each of 
these fields can be found in later paragraphs. 

If an appropriate SAP ID is located, the identity 
manager 203 utilises the call manager 211 to initiate a 
communication from the first communication terminal 

10 101 to the second communication terminal 105. 

Additionally, the call manager 211 performs all the 
normal call related processing (routing, call state 
management, billing functions, etc.) as would be found in 
any existing communications system. 

15 If no SAP ID is found in the domain-user database 

205, then a search is performed in the search domain 
database 207, also local to the first communication 
terminal 101. The search domain database 207 contains 
records for alternative communication domains where it 

20 may be possible to locate a SAP ID for the desired end 

user. Essentially, the Search Domain Database 207 allows 
a variable number of fields to be used as keys to match 
against a complete record stored in the database. When a 
match is found, the complete matching record(s) is(are) 

25 returned. This database 207 contains a record for each 
alternative communications domain where it may be 
possible to locate a record for the called users and the 
specific service. For example, the database 207 may 
contain a SAP ID or routing information to the US on-line 

30 directory inquiries service, or Motorola's on-line 
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directory service, etc.. In the preferred embodiment, the 
contents of the information stored in each record is as 
follows: 

Unique Access Keyword 

Access code for alternative Domain Databases (e.g. SAP ID 

of alternative node) 

Service 

Charging Information 

Once a search database is identified by the search 
domain database 207, the identity manager 203 utilises 
the node to node controller 209 for communicating to 
remote network nodes on the communication link 107. 
The remote network nodes provide similar searching in 
remote network's domain user databases and search 
domain databases for these remote networks. The 
remote network nodes provide one of three services: one, 
they will communicate the appropriate SAP ID back to 
the first communication terminal 101; two, they will set 
up a communication between the first communication 
terminal 101 and the second communication terminal 
103 identified by the desired SAP ID; or three, if an 
appropriate SAP ID is not identified then they will 
communicate a communication request to a second 
remote network node (not shown in FIG. 2). This second 
remote network node will provide the same functionality 
as the first remote network node. 

FIG. 3 is a detailed illustration of the network node 
103 of FIG. 1. The network node 103 includes an identity 


manager 303, a domain user database 305, a search 
domain database 307, two network node controllers 309, 
313, a call manager 311 and a network manger interface 
(NMI) 315. The network node 103 works in much the 
same way as the communication terminal, with the 
following differences. First, the network node 103 
receives communication requests from communication 
terminals via the communication link 107. Second, the 
network node 103 includes the NMI 315. The NMI 
provides a network manager with an interface through 
which he may modify any of the records stored in either 
the Domain-User Database or the Search Domain Database 
in a remote node. Through this interface, the network 
manager is able to, for example, change the SAP ID for a 
given user because he has moved to a new location, 
change the complete numbering plan for a given 
network, add or remove records for external sources 
which might provide information about how the called 
user may be reached. 

To illustrate the capabilities of this invention, two call set 
up scenarios are described below. 

Sfftnario 1 • s«t up a c all to a called user who the caller 

regularly calls 

In this simple scenario, illustrated in FIG. 4, one user calls 
another user on the same system. The calling user has an 
communication terminal in accordance with this 
invention and because he regularly calls the called user 
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he has configured the domain user database m his 
terminal to match a key word with the called user's SAP 
ID The sequence of events for scenario 1 is as follows: 
1 .i The calling user speaks the words "I want to phone 
my wife" into his handset. 

1 ii The MMI in the handset contains a speech 
recognition capability and generates the spoken phrase 
as a text string. 

1 iii The MMI contains a text string parser, which scans 
the text string and re-formats the information into a 
message with at least the following fields: 
Service = Voice Telephony 
Called User Keyword = Wife 
This interpretation is presented to the user for 
confirmation and is confirmed (confirmation is optional). 
1 iv The MMI passes this message to the Identity 
Manager in the handset and the Identity Manager in the 
handset receives this message 

1 v The identity manager in the handset requests the 
Domain-User Database in the handset to find a record for 
the keyword "Wife" and the service "Voice Telephony". In 
the case where multiple users may sequentially use the 
calling handset, the calling user identity is used to 
distinguish which record in the Domain User Database is 
the matching record. 

1 vi The Domain-User Database finds a matching record 
and returns the dialable number "012345 456789" to the 
Identity Manager in the handset. 

1 vii The Identity Manager in the handset, having 
received sufficient information from the Domain-User 
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Database decides that the call can proceed and passes the 
dialable number to the call manager in the handset, along 
with a request to set up the call. 

l.viii The call manager in the handset receives the 
5 request from the Identity Manager in the handset and 
then proceeds to set up the call, in the normal way, by 
sending a call setup request to the node to node 
controller in the handset. 

l.ix The node to node controller in the handset receives 
10 the setup request from the call manager in the handset 
and communicates the request to its peer node to node 
controller in the network node. 

2 The network node sets up the call in the normal way 
by performing routing, switching and call control 

15 functions. This equipment routes the call to the correct 
system access point via a suitable node to node Control 
entity. On this occasion, since the calling user's handset 
has been able to provide the SAP ID for this call, the 
Identity Manager and its associated databases in the 

20 network node are not invoked. 

3. The called user's terminal/handset in this scenario is 
just a normal telephone with no additional functionality, 
the called user's terminal receives the call as normal and 
delivers the call to the called user. 

25 

Scenario 2 : Sen din g a file to a remote office for the first 

time 

In this scenario, as illustrated in FIG. 5, the tremendous 
30 capability of the present invention is more dramatically 
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explored. The basic scenario is that a user wishes to send 
a file to an office for the first time ever. This invention 
saves the user the trouble of having to manually look up 
the appropriate SAP ID or other routing information. In 
addition, once the correct SAP ID or other routing 
information has been determined by the functionality in 
accordance with this invention, the calling user's terminal 
is informed of this new information and is able to store 
the information for future use. 

The sequence of events for scenario 2 is as follows: 

l.i The calling user has a computer file which he wishes 
to send to a Motorola sales office in Argentina. His 
terminal's MMI has a voice input device, so he speaks the 
words "Send this file to the Motorola Sales Office in 
Argentina" into the voice input device. (If no voice input 
device exists, then the calling user can type in the 
appropriate information, perhaps via a formatted input 
screen.) 

l.ii The MMI contains a speech recognition capability 
and generates the spoken phrase as a text string. 
l.iiiThe MMI scans the text string and re-formats the 
information into a message with at least the following 
fields: 

Service = File Transfer 
Name = Motorola Sales Office 
Organisation = Null 
Country = Argentina 

This interpretation is presented to the user for 
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confirmation however the user decides to correct the 
interpretation by saying (or typing) "Organisation is 
Motorola, Name is Sales Office". The MMI corrects the 
interpretation according to the new instructions from the 
calling user. 

l.ivThe MMI passes this formatted message to the 
Identity Manager in the terminal and the Identity 
Manager in the terminal receives this message 
l.v The Identity Manager in the terminal requests the 
Domain-User Database in the terminal to find a record 
matching the fields Name = Sales Office, Organisation = 
Motorola, Service = File Transfer, Country = Argentina. 
l.viThe Domain-User Database does not on this occasion 
find any suitable matching record and returns this fact to 
the Identity Manager in the terminal, 
l.vii The Identity Manager, having failed to get a 
matching response from the Domain-User Database, now 
analyses the fields of information itself and requests the 
Search Domain Database in the terminal to find a 
matching record for Motorola or for Argentina, 
l.ix The Search Domain database does not find matching 
records for either of the requests and reports this fact to 
the Identity Manager in the terminal. 
1.x The Identity Manager in the terminal having no 
further alternatives, forwards the original formatted 
inquiry (Name as Sales Office, Organisation = Motorola, 
Service = File Transfer. Country = Argentina) to the 
network node 1 via the node to node controller in the 
Terminal. 
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2.i The node to node controller in the network node 1 
recognises the formatted addressing information and 
passes this information to the Identity Manager in 
network node 1, which receives this message. 
2.ii The Identity Manager in network node 1 requests 
the network node's Domain-User Database to find a 
record matching the fields Name = Sales Office, 
Organisation = Motorola, Service = File Transfer, Country 
= Argentina. 

2.iiiThe Domain-User Database in the network node 1 
does not on this occasion find any suitable matching 
record and returns this fact to the Identity Manager in 
the network node 1. 

2.ivThe Identity Manager in the network node 1, having 
failed to get a matching response from the Domain-User 
Database in the network node 1, now analyses the fields 
of information itself and requests the Search Domain 
Database in network node 1 to find a matching record for 
Motorola or for Argentina. 

2.v The Search Domain database finds matching records 
for both requests and returns records for the on-line 
Motorola Directory Inquiries server and the on-line 
Argentina Directory Inquiries Server respectively to the 
Identity Manager in network node 1. 
2.viThe Identity Manager in network node 1 receives 
these two records from the Search Domain Database in 
network node 1 and prioritises the two alternatives 
based on an algorithm that includes the cost of searching 
in the remote systems. In the case of cost-based 
priori tisation, it turns out that the Motorola Directory 
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Inquiries server offers a free service, whereas the 
Argentina server costs $2.00 per search, so the Identity 
Manager selects the Motorola server and extracts the 
address of this server from the returned record. 
5 (Alternatively the selection from these two alternative 
can be performed by the calling user himself. This would 
require the alternatives to be sent back up the chain and 
presented to the calling user.) 

2.vii The Identity Manager in network node 1 
10 forwards the original formatted search request (Name = 
Sales Office, Organisation = Motorola, Service = File 
Transfer, Country = Argentina) to the appropriate node to 
node Control entity which is able to communicate the 
request to the on-line Motorola Directory Inquiries 
15 server. 

3.i The node to node controller in the Motorola Directory 
Inquiries server (MDE) recognises the formatted 
addressing information and passes it to the Identity 
Manager in the MDE server, which receives this message. 

20 3.ii The Identity Manager in the MDE requests the 
Domain-User Database in the MDE to find a record 
matching the fields Name = Sales Office, Organisation = 
Motorola, Service = File Transfer, Country = Argentina. 
3.iiiThe Domain-User Database finds a matching record 

25 and returns the matching record to the Identity Manager 
in the MDE. 

3.ivThe Identity Manager in the MDE is not able to set 
up the call to the Motorola Sales Office in Argentina, since 
it does not have a suitable node to node controller, so the 
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matching record is returned to network node 1 via the 
appropriate node to node controller. 
2.viii The node to node controller in network node 1 
receives the record and passes it to the Identity Manager 
in network node 1. 

2.ix The Identity Manager in network node 1 extracts the 
appropriate SAP ID and/or routing information from the 
record and instructs the call manager in network node 1 
to set up the appropriate call. The Identity Manager in 
network node 1 also transmits the matching record back 
in the direction of the calling user's node via the 
appropriate node to node controller. 

1 .xi The matching record is received in the calling user's 
terminal via the node to node controller in that terminal. 
The node to node controller passes this record on to the 
Identity Manager in the terminal. 

l.xiiThe Identity Manager in the terminal receives this 
record, and instructs the Domain-User Database in the 
terminal to store the new record. 

l.xiii The Domain-User Database in the calling user's 
terminal stores the new record for future use. 

Note: the address of the Motorola Directory Inquiries 
service may also be returned to the calling user's 
terminal, where it would be stored in the Search Domain 
Database. Future requests by this user for 
communications to Motorola could then bypass the 
identity matching functions of the network node and 
directly ask the Motorola Directory Inquiries equipment. 
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2.viii The call manager in network node 1 sets up the 
service connection via a second network node (4) in 
Argentina to the Sales Office Equipment in Argentina (5) 
and the service is executed. 

5 

Other foreseeable services provided in the preferred 
embodiment. 

Restricted Access (e.g. Ex-directory) 

10 

It would be essential that users identities such as "The 
Queen at Buckingham Palace" are not abused. The 
equivalent of going ex-directory must be supported in by 
this invention. This is achieved by having a field entitled 

15 "Access Control Rule" in each record of the Domain-User 
Database. In this field is stored a password, DTMF 
sequence, authentication and encryption rule or 
whatever means of security the called user employs to 
protect against unwanted callers. In the case of password 

20 protection, no record will be returned by the Domain- 
User Database without the correct password being 
supplied. In this way the called user can prevent 
malicious calls by only providing the password 
information to selected other users. Some agencies such 

25 as the police may not be required to provide the 
password for obvious reasons. 

Route Selection 
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It may be possible that one called user may have 
multiple subscriptions for the same or similar services. 
For example a user may have a fixed telephone line 
subscribed through one network operator and a mobile 
5 phone subscribed through another network operator, 
both of which are capable of delivering the voice 
telephony service. The choice of which network to select 
(i.e. which SAP ID) as the matching SAP ID for the called, 
user id made by the Identity Manager, based upon some 
10 algorithm such as minimum cost, maximum likelihood of 
success, voice quality, etc. The various alternatives are 
stored in priority order in the "Prioritised dialable 
Number(s)" field of each record in the Domain-Users 
Database. 


15 


Furthermore, there may be multiple routes available for 
setting up the call to a specific SAP ID - this manifests 
itself amongst other things in the determination of which 
node to node controller is selected during call setup. The 
20 various routes are prioritised according to some 

algorithm such as minimum cost, maximum quality, etc. 
This priority can change according to time of day or some 
other algorithm and this information is stored in the field 
named "Prioritised List of Gateway Domains". 


25 


Intelligent Re-Routing for Roaming Called Users 


Although the called user may be known to the calling 
user by a particular user identity, such as "Bill Robinson 
30 at Motorola, UK", the information stored in the Domain- 
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User Database can be used to re-route calls to the called 
user in circumstances where the called user has roamed 
to an alternative location, (e.g. traveled to another 
network in another country). The Identity Manager in 
5 one of a suitable nodes intercepts the call setup process 
and re-routes the call setup to the new destination, the 
location of which is provided by a record in the Domain- 
User Database. 

10 Access to User's Home Databases from Another Terminal 

The user's own Domain-User Database and Search Domain 
Database may be stored in a removable User Identity 
Module, such as a SIM card or equivalent. If this is the 
15 case, when the user roams to a remote location and uses 
different terminal, he simply inserts his SIM into the 
terminal in the normal way and all his own database 
information is available to him. 

20 Where it is the case that the Domain-User Database and 

Search Domain Database are stored in the user's terminal, 
and not in a removable SIM, the method of accessing the 
user's own databases from a remote location must clearly 
be different. In this case, the user knows that his own 

25 database contains certain records that may not be 

present in the remote terminal he is using. In order to 
reduce the cost and time penalty incurred by searching 
for routing information pertaining to a specific called 
user through successive databases in various network 

30 nodes, the user can instruct the search to be performed 
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controller for accessing one of a plurality of network 
nodes; and 

a first network node for receiving a communication 
requests from the first communication terminal and 
5 providing a service chosen from the group consisting of 
SAP ID communication to the first communication 
terminal, communication set-up between the first 
communication terminal and the second communication 
terminal using the desired SAP ID, and communication of 
10 the communication request to a second network node. 

7. A communications addressing network in accordance 
with claim 6 wherein the first communication terminal 
further comprises: 
15 a man-machine interface (MMI) for interfacing to the 

first user and generating the communication request; 

an identity manager for identifying the SAP ID in 
response to the communication request from the MMI; 
a domain-user database for use by the identity 
20 manager for searching for the SAP ID using the 
communication request; 

a search domain database for use by the identity 
manager for searching for alternate search domains for 
searching for the SAP ID using the communication 

25 request; and 

a call manager for communicating to the second 
communication terminal via the SAP ID provided by the 
identity manager. 
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8. A communications addressing network in accordance 
with claim 7 wherein the communication requests 
further comprises a message having at least one field 
chosen from a group consisting of Service Type, 

5 Organization, Country, and Name. 

9. A communications addressing network in accordance 
with claim 8 wherein the Service Type includes a 
predetermined service type chosen from a group 

10 consisting of voice service, data service, video service, 
and file transfer service. 

10. A communications addressing network in accordance 
with claim 7 wherein the domain-user database has a 

15 plurality of SAP ID records, wherein each SAP ID record 
at least one field chosen from a group consisting of SAP 
ID, User Name, Organisation, Access Control Rule, 
Address, Prioritised Dialable Number's 
Present Domain ID, Service, Charging Information, and 

20 Prioritised List of Gateway Domains. 

11. A communications addressing network in accordance 
with claim 7 wherein the MMI further comprises means 
for transforming a user input into a communication 

25 request, said means for transforming including 

transforming the user input from a first media type to a 
text media and formatting the user input into a 
predetermined communication request format. 
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12. A communications addressing network in accordance 
with claim 6 wherein the first network node further 
comprises: 

an identity manager for identifying the SAP ID in 
5 response to the communication request from the first 
communication terminal; 

a domain-user database for use by the identity 
manager for searching for the SAP ID using the 
communication request; 
10 a search domain database for use by the identity 

manager for searching for alternate search domains for 
searching for the SAP ID using the communication 

request; and 

a call manager for communicating to the second 
15 communication terminal via the SAP ID provided by the 
identity manager. 

13. A communications addressing network in accordance 
with claim 12 wherein the first network node further 
20 comprises a network-manager interface (NMI) for 

modifying information contained in the domain-user 
database or the search domain database. 
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